Many data transfer systems used today for exchanging data between network devices employ packet-switched networks and use communication protocols included in the Internet Protocol (IP) suite. Particulars of definitions of a number of communication protocols are controlled by the Internet Engineering Task Force (IETF) in a series of Request for Comments (RFC) documents. For example, aspects of the Internet protocol suite are defined in RFC 1122 and RFC 1123.
The protocols most used on the Internet today include the Transmission Control Protocol (TCP) and the User Datagram Protocol (UDP) which, while a number of alternatives exist, are widely carried via the IP suite. TCP provides a number of functions not provided by UDP. For example, TCP can be used to ensure that data packets are submitted by a source network device at a rate supported by the intermediate network and destination network device, or that data packets can be transmitted to a destination network device and reassembled in an intended sequence. UDP does not provide the sequencing or flow control addresses to network operators by regulating authorities, have forced solutions that support more network devices on the Internet than there are public IP addresses but yet circumvent limitations due to exhaustion of IPv4 address space.
One solution is to transition the Internet to IP version 6 (IPv6), which provides a vastly increased 128 bit address space. However, in order to provide its benefits network wide, virtually all network infrastructure is required to support IPv6. To date, not all network infrastructure supports IPv6, and upgrades to IPv6 are still ongoing. Adoption of IPv6 is slow because it partially entails costly infrastructure upgrades. IPv6 does not provide an imminent solution to the IPv4 address space dilemma.
Another solution is based on private IP addresses for which a fraction of the IPv4/IPv6 address space has been set aside for special purpose uses in private IP networks. In contrast to a public IP address, a private IP address can be used multiple times in two or more network segments without risk of collision as the private IP addresses are not reachable from a public network. Sending data packets to private IP addresses from devices with public IP addresses is not possible without special provisions provided by some forms of Network Address Translation (NAT), for example. As such private IP addresses are commonly characterized as being not globally routable because no data can be sent to them from public IP addresses without further network configuration. Possible gains from multiple usages of private IP addresses, however, are offset by the comparatively small private address space (the number of private IP addresses) for IPv4 and the complex processing required for addressing private IP addresses.
A similar solution to the above can be carried out for IPv6. However, in this case, a local IP address may be used in place of a private IP address. For example, the local IPv6 address may be a Unique Local Address which is still officially globally reachable. Therefore, there may still be a low risk of collision when using IPv6 local IP addresses. However, IPv6 Unique Local Addresses will not typically be made easily known outside the private network. Therefore, for at least some practical purposes, these addresses may be considered to be sufficiently non-routable from outside of the local network.
Network Address Translation (NAT) mitigates the shortcomings of private networks but increases network complexity and maintenance requirements. A NAT device, typically a router, connects one part of a network (a private network) with another part of a network (a public network). NAT exists in a number of forms: For example, basic NAT simply translates certain IP addresses of a data packet; Network Address Port Translation (NAPT) additionally translates ports. Basic NAT and NAPT, however, require initial communication from a private/local IP address to a public IP address. Bi-directional NAT enables communication from a public IP address into a private network without requiring prior communication from the private/local IP address; NAT-PT enables interconnecting IPv4 and IPv6 networks; and Realm Specific IP (RSIP) overcomes certain issues caused by embedding network addresses in the payload of data packets.
Generally NAT maps one or more private network addresses of outbound (from the private network) data packets to a public IP address associated with the NAT device. For this purpose NAT uses rules stored in translation tables to map destination addresses of outbound data packets and to determine how to reverse map destination addresses of inbound (to the private network) data packets back into private network addresses. Depending on the form of the NAT, rules may be preconfigured or generated in response to outbound data packets and/or only used until they expire. Some forms of NAT also perform port mapping. Private and public IP addresses are defined in RFC 1918. NAT, NAPT, Bi-directional NAT, NAT-PT and Realm Specific IP (RSIP) are described in a number of documents, for example, RFC 2663, RFC 2766 and RFC 3022.
Other extensions have been developed that recoup interconnectivity functions lost due to NAT but which are otherwise available in NAT-free network connections. These extensions typically concern connecting small numbers of network devices to the Internet. Further extensions have been developed in an attempt to enable NAT to connect networks that allow large numbers of network devices with private IP addresses to connect to the Internet and provide a minimum of interconnectivity functions for them. Known extensions are described by B. Landfeldt et al. in “Providing Scalable and Deployable Addressing in Third Generation Cellular Networks”, School of Electrical and Information Engineering and School of Information Technologies, The University of Sydney, Australia, as well as in U.S. Pat. Nos. 7,139,828 7362,760. Further documentation referring to or describing various aspects of NAT include the Internet Gateway Device (IGD), Simple Service Discovery Protocol (SSDP), Universal Plug and Play (UPnP), Devices Profile for Web Services (DPWS), NAT-Port Mapping Protocol (NAT-PMP), Zero Configuration Networking (Zeroconf) and Jini™, for example. Existing forms of NAT, however, can be complex, cumbersome and error-prone, and extensions typically fail to provide required scalability or even rudimentary security features.
Furthermore, data may be delivered to network devices, for example, in cellular networks using a Mobile Subscriber Integrated Services Digital Network Number (MSISDN). The MSISDN is used for example in Short Message Service (SMS) communications and when setting up packet-based communications. Some aspects of packet-based communication with or without MSISDN are noted in 3rd Generation Partnership Project, Specification Group: TSG Service and System Aspects (TSG-SA), Meeting #50, Agenda Item 11.13: “LS from CT WG3: Reply LS on direct stage 3 work for NIMTC functionality,” (Incoming Letter) Ref. #SP-100664, Dec. 13-15, 2010, ftp://ftp.3gpp.org/tsg_sa/TSG_SA/TSGS—50/Docs/SP-100664.zip, for example. Using SMS and/or MSISDN, however, requires special configuration of network infrastructure and additional network resources which may not be cost and/or network traffic effective.
Although the MSISDN includes 15 decimal digits, several digits are reserved for certain designations which severely reduces the MSISDN address space. The increased use of network devices for machine to machine communication (M2M), for example, for wireless communication with hydro or gas meters, has accelerated MSISDN address space exhaustion. In response some regulating authorities have restricted the use of MSISDN for use with human-to-human (H2H) communication.
Therefore there is a need for a solution that overcomes at least one of the deficiencies in the prior art.
This background information is provided to reveal information believed by the applicant to be of possible relevance to the present technology. No admission is necessarily intended, nor should be construed, that any of the preceding information constitutes prior art against the present technology.